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ABSTRACT 

This  paper  addresses  the  bandwidth  and  latency  optimization  of  Embedded  Simulation  (ES)  communications 
within  tactical  Command,  Control,  Communications,  Computers,  Intelligence,  Surveillance,  and 
Reconnaissance  (C4ISR)  networks  while  supporting  an  Enroute  Mission  Planning  and  Rehearsal  (EMPR)  for 
ground  combat  vehicles  and  other  use  cases.  Simulation  data  obtained  from  One  Semi  Automated  Forces 
(OneSAF)  Testbed  Baseline  simulations  is  consistent  with  Future  Combat  Systems  (FCS)  Operations  and 
Organizations  scenarios  of  multiple-platoon,  company,  and  battalion-scale  force-on-force  EMPR  vignettes. 
The  resultant  simulation  traffic  is  modeled  and  assessed  within  a  hierarchical  communication  architecture 
consisting  of  Manned  Platforms,  Distributed  Common  Ground  Systems  (DCGS_A)  and  Multiband  Integrated 
Satellite  Terminal  (MIST)s  interconnected  to  Joint  Tactical  Training  System  (JTRS)  and  Warfighter 
Information  Network-Tactical  (WIN_T)  networks,  as  foreseen  by  Future  Combat  Systems  (FCS).  The 
mentioned  battle  support  vehicles  operate  as  routers  and  hubs  that  interconnect  Unmanned  Air  Vehicles 
(UAV),  Unmanned  Ground  Vehicles  (UGV),  Apache  Helicopters  (Ah64)  and  Land  Warriors  (LW)  with 
Continental  United  States  (CONUS)  based  on  a  wireless  C4ISR  network  infrastructure.  The  entire  operation 
is  directed  and  controlled  via  a  CONUS  based  ground  station  and  its  corresponding  satellite  network. 

Within  this  environment,  three  areas  of  ES  bandwidth  and  latency  research  are  addressed:  Simulation  Traffic 
Analysis,  Data  Transmission  Optimizations,  and  Traffic  Modeling  Tools  /  Demonstration  sets.  Simulation 
Traffic  Analysis  tasks  include  the  development  of  a  tentative  network  for  FCS  and  Simulator  Training  systems 
that  can  be  used  to  analyze  Packet  Data  Unit  (PDU)  transmissions  of  the  most  critical  entity  actions  and 
assessment  of  the  operational-distribution  of  PDUs.  Future  Data  Transmission  Optimization  tasks  include  the 
development  of  burst-free  transmission  scheduling,  PDU  replication,  data  compression,  and  OPFOR  control 
hand-off  techniques.  Traffic  Modeling  Tool  activities  include  the  creation  of  libraries  for  network  capacity 
planning  and  a  self-contained  traffic  modeling  demonstration  package  using  Omnet++.  Within  this 
environment,  we  present  results  for  capacity  estimates  for  ES  bandwidth  in  FCS  battle  applications. 
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FCS  Bandwidth  Optimization  Problem. 

Over  the  past  decade,  the  U.S.  Army’s  principal  modernization  initiative  has  been  its  digitization  effort, 
designed  to  significantly  improve  the  fighting  capabilities  of  soldiers  on  the  battlefield.  But  implementing  that 
initiative  presents  significant  challenges.  Digitization  requires  the  rapid  transmission  of  large  amounts  of 
information  over  significant  distances.  Experiments  conducted  to  date  as  well  as  recent  operations  in  Iraq, 
where  troops  employed  some  of  the  results  of  the  service’s  digitization  efforts,  have  shown  that  that 
requirement  is  difficult  to  fulfill  in  any  terrain  conditions. 

Consequently,  the  focus  of  the  Army’s  modernization  program  has  shifted  in  1999  to  what  it  terms 
transformation — making  its  forces  deployable  more  quickly  while  maintaining  or  improving  their  lethality  and 
survivability.  Although  digitization  is  no  longer  the  Army’s  primary  modernization  initiative,  it  remains  a  key 
element  of  transformation.  In  the  past  several  years,  questions  about  the  size  of  the  information  flow 
associated  with  digitization  and  the  communications  bandwidth  to  support  it,  have  spurred  the  Army  to  adopt 
several  large  radio  and  network  communications  programs  to  study  the  total  network  capacity  of  Training 
Simulations  and  Real-Time  battle  communications  to  predict  future  FCS  design  considerations. 

Future  bandwidth  demand  shall  increase  as  suggested  by  Rehmus[1]  on  his  report  to  the  Congressional 
Budget  Office  (CBO).  He  predicts  that  the  peak  network  demands  for  the  year  2003  are  greater  at  the  Brigade 
and  Battalion  levels  by  a  factor  of  10  to  20  when  compared  to  standard  network  demands  for  networks  that 
serve  the  Operations  Officers  (ops  nets).  That  is,  one  message  arrives  on  time  for  every  10  to  20  sent. 
Future  advances  in  communications  equipment  that  the  Army  plans  to  support  include  Joint  Tactical  Radio 
System  (JTRS),  Warfighter  Information  Network-Tactical  (WIN-T)  and  Multiband  Integrated  Satellite  Terminal 
(MIST)  to  further  support  communications  at  the  brigade  division  and  corps  command  levels  increasing 
further  the  bandwidth  needs.  FCS  shall  exceed  the  current  demands  by  10  fold  at  the  Corps  and  Division 
Command  areas,  due  to  the  increase  in  video  and  imaging  information^].  In  addition,  lower  communication 
noticed  at  other  command  levels  will  also  increase  in  the  future  due  to  the  added  support  systems  and 
unmanned  vehicles  planned  for  FCS  use. 

Foreseeing  the  immense  bandwidth  needs,  the  Army  is  trying  to  reduce  its  current  bandwidth  demands  by 
slashing  functionality.  Broadcasting  UAV  images,  teleconferencing  and  other  bandwidth  intensive  applications 
is  no  longer  possible.  Useful  information  has  been  replaced  or  eliminated  to  accommodate  the  existing 
network  technology  such  as  JTRS  and  WIN-T.  Ironically,  decreasing  bandwidth  needs  reduces  the  success  of 
the  Army’s  digitization  Initiative. 

The  Army  faces  a  number  of  problems  in  implementing  its  IT  strategy  on  the  battlefield.  The  service  needs 
much  more  bandwidth  than  it  has  available  today  to  support  both  its  current  systems  and  those  planned  for 
the  future.  Being  Bandwidth  the  central  issue  for  the  communications  system,  we  propose  to  study  the  future 
network  requirements.  Unfortunately,  real  time  bandwidth  measurements  are  rather  complex,  particularly 
when  the  network  topologies  are  not  well  defined.  To  analyze  the  communication  needs  we  propose  to  obtain 
Semi-Automated  Forces  (SAF)  data  from  the  OneSAF  Testbed  Baseline  Simulator  (OTB),  used  by  the  Army 
to  plan,  execute  and  review  battles  in  remote  locations.  OneSAF  can  provide  useful  data  to  further  study  the 
future  network  requirements  of  FCS.  Then,  using  a  network  constructive  discrete  simulator  such  as 
OmNet++[2],  it  is  possible  to  further  study  the  future  bandwidth  needs  and  suggest  possible  optimizations. 

Bandwidth  considerations  for  FCS  Simulation  model. 

FCS  networks,  vehicles  and  system  functionality  depend  on  existing  and  emergent  technologies.  Thus, 
effective  bandwidth  measurements  for  future  combat  systems  are  difficult  due  to  the  inventiveness  of  the 
designs.  However,  certain  Bandwidth  expectations  for  certain  vehicles  are  estimated  based  in  information 
provided  by  Army  Subject  Matter  Experts  (SME)  [5].  Data  rates  have  been  assigned  for  certain  vehicles  for 
voice,  data  and  imagery.  Table  1  lists  the  effective  data  rates  for  FCS  vehicles. 


FCS  Vehicles  and  Effective  Bandwidth. 
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Aerial  Common  Sensor 

D.l 

60 

60 

60 

6144 

1000 

10 

AQF/Prophet 

D 

30 

60 

1000 

10 

AWACS 

Comanche 

Global  Hawk/Predator 

V 

1 

100  20 

5 

5 

6144 

1000 

10 

UAV 

D,l 

300 

60 

300 

6144 

1000 

10 

J-STARS 

NA 

NA 

NA 

NA 

NA 

NA 

NA 

Rivet  Joint 

D 

300 

60 

Satellite 

D.l 

600 

60 

600 

6144 

U-2  ASARS  II 

D.I.V 

300 

60 

300 

6144 

1000 

10 

Unmanned  Aerial  Vehicle 
(UAV  CL  1) 

Unmanned  Aerial  Vehicle 

D.I.V 

0.017 

5 

10 

410 

1000 

10 

(UAV  CL  II) 

Unmanned  Aerial  Vehicle 

D.I.V 

0.017 

5 

10 

410 

1000 

10 

(UAV  CL  III) 

Unmanned  Aerial  Vehicle 

D.I.V 

0.017 

5 

10 

820 

1000 

10 

(UAV  CL  IVa) 

Unmanned  Aerial  Vehicle 

D.I.V 

0.017 

5 

10 

820 

1000 

10 

(UAV  CL  IVb) 

Unmanned  ARV-A(L)  (2.5 
ton) 

D.I.V 

0.017 

5 

10 

410 

1000 

10 

Unmanned  ARV-RSTA  (6 
ton) 

Unmanned  Ground 

D.I.V 

0.017 

5 

10 

820 

1000 

10 

Vehicle  (MULE) 
Unmanned  Ground 

D.V 

0.017 

5 

192 

86400 

Vehicle  (SUGV) 

D.I.V 

0.017 

5 

10 

820 

1000 

10 

Table  1:  FCS  Vehicles  Effective  Bandwidth. 


Tanenbaum  [6]  defines  Bandwidth  as  the  range  of  frequencies  transmitted  without  being  strongly  attenuated. 
It  can  be  attenuated  as  transmission  distances  increase.  Bandwidth  units  for  digital  media  is  known  as  Bit 
Rate,  the  number  of  bits  per  second  transmitted;  not  to  be  confused  with  Baud  Rate  the  number  of  signal 
changes  per  second.  Bit  Rate  and  Baud  Rate  are  related  by  the  following  equation. 

Bit  Rate  =  log2  M  *  Baud  Rate  [7] 

Therefore,  Bandwidth  decreases  with  distance  and  terrain  interference  and  transmission  medium  used,  an 
additional  channel  characteristic  that  needs  to  be  modeled  when  building  C4ISR  network  channels.  Note  that 
Throughput  is  analogous  to  Bandwidth. 

Communications  traffic  can  be  thought  of  either  approximately  continuous  or  episodic.  In  the  former  case, 
called  continuous-flow  information  (throughput),  a  bit  per  second  (bps)  is  the  relevant  measure;  in  the  later 
case,  referred  to  as  episodic,  the  size  of  the  message  file  (in  bits)  is  the  appropriate  gauge.  Table  1  one 
depicts  voice,  data,  video  and  imaging  throughput  for  the  most  common  vehicles.  Notice  that  some  vehicles 
transmit  voice  data  only,  as  the  Airborne  Warning  and  Control  System  (AWACS),  while  others  transmit  voice, 
video  and  images  using  the  same  channel,  e.g.  UAV. 

Building  a  network  simulation  using  OmNet++  modules  to  represent  FCS  network  communications  is 
possible.  The  resultant  Bandwidth  capacity  of  the  C4ISR  based  FCS  network  can  be  simulated  by  encoding 
the  corresponding  wireless  channels  and  their  bandwidth  capacity.  Satellites,  Vehicles  and  Land  Warriors 
can  be  modeled  as  network  components  with  specific  data  generation  characteristics  and  effective  bandwidth. 
Since  all  modules  in  the  system  transmit  in  broadcast  mode  (DIS  specification),  the  overall  network 
throughput  and  the  channel  collisions  can  be  analyzed  to  optimize  the  available  bandwidth.  Moreover, 
channel  bottlenecks  and  slack  time  can  be  studied  to  further  optimize  the  overall  throughput.  However, 
simulation  and  modeling  and  the  software  that  makes  then  function  is  designed  according  to  certain 
assumptions  about  the  communications  network  in  which  they  operate  and  the  rates  of  information  available 
as  parameters.  Therefore,  the  results  of  this  experimental  simulation  are  an  attempt  to  provide  measurable 
results  and  determine  the  possible  network  tribulations  that  future  combat  systems  may  present  as  they 
intercommunicate  through  different  networks  and  satellite  links  in  benign  environments. 


OMNet++  Modeling 


OMNeT++  is  a  discrete  event  simulation  environment.  Its  primary  application  area  is  the  simulation  of 
communication  networks,  but  because  of  its  generic  and  flexible  architecture,  is  successfully  used  in  other 
areas  like  the  simulation  of  complex  IT  systems,  queuing  networks  or  hardware  architectures  as  well.  The 
simulator  provides  component  architecture  for  models.  Components  (modules)  are  programmed  in  C++,  then 
assembled  into  larger  components  and  models  using  a  high-level  language  (NED).  Models  are  provided  free 
of  charge[3]. 

For  this  particular  simulation  we  choose  to  model  a  communications  topology  based  on  a  battle  scenario 
suggested  by  the  Army  SME.  The  used  case  involves  land-unmanned  vehicles,  air  and  land  support  and 
UAVs,  all  communicating  at  a  Brigade  level.  (A  brigade  is  the  smallest  Army  force  structure  that  utilizes  a 
satellite  link  [1].  A  brigade  is  typically  commands  the  tactical  operations  of  two  to  five  organic  or  attached 
combat  battalions.  Normally  commanded  by  a  colonel  with  a  command  sergeant  major  as  senior  NCO, 
brigades  are  employed  on  independent  or  semi-independent  operations.  Armored,  cavalry,  ranger  and 
Special  Forces  units  are  categorized  as  regiments  or  groups  [2]). 

Four  communication  channels  are  necessary  and  modeled  according  to  the  characteristics  suggested  in 
C4ISR  document  for  wireless  communication  [4]  and  the  bandwidth  predictions  for  JTRS  (200  Kbps)  and 
WIN_T  (2.5  Mbps)  networks  obtained  from  [1]. 

The  following  figure  1  is  generated  by  the  OMNet++  simulator  and  depicts  the  current  network  layout.  The  first 
channel  is  the  wireless  ground  to  satellite  (wirelessGS.)  This  channel  connects  CONUS  networks  with  the 
satellite  network  that  transmits  battle  command  information  to  remote  locations  all  over  the  world.  The  second 
channel,  wireless  to  ground  network  (wirelesWSGN)  supports  apache  helicopters  (AH-64)  and  Distributed 
Common  Ground  Systems  (DCGS)  vehicles  that  serve  as  a  router  to  WIN_T  networks.  The  third  channel, 
WIN_T  connects  DCGS  vehicles  with  Manned  Platform  Vehicles  as  they  also  serve  as  a  router  for  JTRS 
networks.  The  last  and  fourth  channel  connects  wirelessly  all  Unmanned  Ground  Vehicles  (UGV),  Unmanned 
Air  Vehicles  (UAV)  and  Land  Warriors  (LW)  together. 


Figurel:  OMNet++  C4ISR  network  channel  connections  for  WIN-T  and  JTRS  networks. 


Each  channel  depicted  in  blue  (elongated  rectangles),  serve  as  a  bus  that  transports  data  from  one  network 
channel  to  the  other.  Channels  are  modeled  according  to  the  channel  characteristics  of  the  protocol,  e.g., 
Wireless  LANs  use  IEEE  802.11  protocol. 


Models  connect  to  each  channel  using  nodes  a  sub-module  provided  by  the  channel.  There  is  a  one  to  one 
correspondence  between  modules  and  channel  nodes.  Figure  1  depicts  several  green  colored  circles,  these 
are  the  packets  sent  by  each  host  generator.  Each  module  is  defined  according  to  the  desired  module 
specification  and  characteristics. 


A  simple  module  contains  a  Generator  and  a  Sink.  Generators  are  sub-modules  programmed  to  generate 
packets  at  their  discrete  time  only  limited  by  the  throughput  of  the  channel  it  connects  to.  Generators  will 
broadcast  a  packet  when  the  packet’s  time  is  due.  If  the  packet  is  to  be  sent  at  time  t,  but  the  bus  due  to  its 
limited  bandwidth  cannot  service  it,  a  negative  time  slack  is  created  and  recorded.  If  the  packet  leaves  on 
time,  a  positive  slack  is  recorded.  If  the  packet  is  serviced,  but  on  his  way  out  to  the  channel  collides  with  an 
incoming  packet,  a  collision  is  detected  and  recorded.  The  Sink  on  the  other  hand,  will  retrieve  packets  from 
the  channel  with  a  destination  address  of  -1  (Broadcast  Destination)  or  its  own  destination  (network 
dependent  number).  Figure  2,  depicts  the  internal  configjjration_a  UAV  as  shown  by  OMNet++. 


Figure  2:  UAV  internal  sub-modules. 


The  Generator  can  be  programmed  to  create  data  packets  at  a  specific  data  rate  and  size  or  it  can  read  data 
from  data  text  files  a  rate  determined  by  each  in  packet’s  timestamp.  When  data  from  an  Army  simulator  is 
provided  such  as  OneSAF,  data  can  be  parsed  and  reorganized  to  be  read  later  by  the  Generators.  Figure  3 
depicts  the  current  data  format  for  packet  generation  using  a  text  file,  therefore  for  this  method,  data  from 
OneSAF  needs  to  be  parsed  accordingly  to  meet  the  following  requirements. 


Column  1  contains  packet  time  information  in  Hexadecimal  1/100  of  a  second.  The  next  column  contains  the 
packet  size  information.  Original  data  is  converted  to  generate  columns  three  and  four.  The  Generator  module 
reads  the  data  text  file  and  generates  Column  3  which  contains  the  converted  time  in  Min:Seconds.Hundreths 
of  a  second.  Column  4  contains  the  line  number. 
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Figure  3:  Data  format  for  packet  generation  using  a  text  file. 

In  cases  where  a  single  module  will  generate  three  different  types  of  data,  three  Generators  will  be  contained 
in  each  module,  one  for  each  data  type  and  rate. 

Once  all  network  components  are  in  place,  different  network  configurations  can  be  explored  by  rearranging 
the  connections  to  the  channels.  Statistical  results  based  on  different  simulations  can  be  used  to  aid  future 
designs.  The  goal  is  to  determine  if  the  current  bandwidth  utilization  is  wide  enough  to  accommodate  FCS. 

Simulation  Results 

Peak  effective  bandwidth  demand  for  future  combat  systems  can  exceed  the  current  expectations.  The  Army 
has  studied  the  peak  demands  for  continuous  flow-information  on  division,  brigade  and  battalion  levels  for  the 
digitized  division.  The  study  has  found  that  peak  effective  bandwidth  can  be  between  2.5  Mbps  and  4  Mbps. 
Our  intent  is  to  find  the  possible  bottlenecks  in  the  system  and  further  optimize  transition  to  obtain  better 
bandwidth  optimization. 

Vehicles  such  as  the  Manned  Platforms,  Army  Battle  Command  System  (ABCS)  and  the  DGCS  act  as 
centers  of  communication  in  the  battlefield.  Such  vehicles  act  as  routers  for  the  JTRS  and  WIN  T  networks 


and  Satellites  used  in  battle  at  the  Brigade,  Division  and  Corps  levels.  These  vehicles  are  suspects  of  intense 
collisions  due  to  the  intense  routing  they  perform.  The  present  simulation  shall  provide  collision  information  on 
these  vehicles  as  results  are  obtained  from  OTB  sample  data.  Unfortunately,  the  used  cases  utilized  for  FCS 
using  OTB  have  not  yet  been  released  as  unclassified.  Such  data  and  the  results  of  the  proposed  OMNet++ 
simulation  shall  be  available  prior  to  the  oral  presentation. 

However,  the  following  graph  presented  on  figure  4,  depicts  the  bandwidth  utilization  results  of  an  earlier 
simulation  at  the  satellite  module  using  similar  OMNet++  models  that  supported  Joint  Tactical  Training 
System  (JTRS).  The  OTB  vignette  supported  six  C-130  Hercules  air  carriers  on  flight  and  the  communication 
between  them  as  a  battle  training  simulation  was  executed  inside  the  three  vehicles  that  each  plane 
transports.  Data  used  on  this  Omnet++  simulation  was  also  obtained  from  OTB.  It  is  easy  to  observe  that  a 
200  Kbps  channel  is  necessary  at  the  satellite  link  to  provide  optimal  service. 


Experiment  #3  (6  sites) 


Time  in  seconds 


Figure  4:  Bandwidth  Utilization  Results 

The  suggested  data  rates  depicted  on  table  1  for  the  unmanned  vehicles  are  ready  to  be  used  and 
incorporated  into  the  respective  modules  and  provide  additional  data  to  the  JTRS  and  WIN_T  networks.  As 
we  receive  the  Army  OTB  unclassified  data  that  represents  the  bandwidth  utilization  of  our  C4ISR  proposed 
network,  our  simulation  shall  produce  similar  results  as  proved  useful  in  earlier  simulations. 


References 

[1]  Rehmus,  P.  Gilmore,  M.  (2003)  The  Army’s  Bandwidth  Bottleneck.  [Electronic 
Version]  The  Congress  of  the  United  States,  Congressional  Budget  Office,  Washington 
DC,  August.  Retrieved  November  19,  2003,  from 
http://www.iwar.org.uk/rma/resources/cbo/08-28-Report.pdf 

[2]  The  Army’s  Force  Structure.  Retrieved  November  28,  2003,  from 
http://www.militarydial.com/army-force-structure.htm 

[3]  OMNet++  Discrete  Event  Simulator  System.  Retrieved  on  November  26,  2003,  from 

http://www.omnetpp.org/. 

[4]  Web,  Richard.  C4ISR  Architecture  Framework  2.0.  (1997,  December)  Retrieved  on 

November  26,  2003  from 

http://www.defenselink.mil/nii/org/cio/i3/AWG_Digital_Library/pdfdocs/fw.pdf 

[5]  Francis,  Paul  L.  Understanding  FCS.  (2003  August)  Retrieved  on 

October  26,  2003  from 
http://www.gao.gov/new.items/d031010r.pdf 


[6]  Tanenbaum,  Andrew  S.  Computer  Networks.  4th  ed.  (2002)  Prentice  Hall 

[7]  Spragins,  John  D.  Telecommunications:  Protocols  and  Design.  (1992)  Addison- 
Wesley  Publishing  Company,  Inc. 


BIOGRAPHIES 

Carlos  Leon-Barth  is  a  Research  Assistant  and  Ph.D.  student  in  the  Department  of  Electrical  and  Computer 
Engineering  at  the  University  of  Central  Florida.  He  earned  a  BS  (1993)  in  Electrical  Engineering  from 
University  of  Florida,  MS  (1996)  in  Computer  Engineering  from  the  University  of  Central  Florida.  He  was 
previously  a  Consulting  Engineer  for  IBM  Global  Services  in  Armonk,  New  York  from  1996-2002.  His 
research  interests  are  performance  analysis  of  Computer  Networks  and  Simulation. 

Ronald  F.  DeMara  is  an  Associate  Professor  in  the  Department  of  Electrical  and  Computer  Engineering  at 
the  University  of  Central  Florida.  He  earned  a  BS  (1987)  in  Electrical  Engineering  from  Lehigh  University,  MS 
(1989)  in  Electrical  Engineering  from  the  University  of  Maryland,  and  Ph.D.  (1992)  in  Computer  Engineering 
from  the  University  of  Southern  California.  Prior  to  joining  UCF,  he  was  an  Associate  Engineer  at  IBM 
Corporation  in  Manassas,  Virginia.  His  research  interests  include  design  and  performance  analysis  of 
Computer  Architecture  and  Distributed  Systems.  He  has  published  over  80  papers  in  these  areas.  He  is  a 
registered  Professional  Engineer  in  California,  senior  member  of  IEEE,  a  member  of  ACM,  and  ASEE. 


Henry  Marshall  is  the  Principal  Investigator  for  Mounted  Embedded  Simulation  Technology  at  the  Research, 
Development  and  Engineering  Command  (RDECOM)  Simulation  and  Training  Technology  Center  (STTC). 
Prior  to  this  assignment  he  worked  at  the  Simulation,  Training  and  Instrumentation  Command  (STRICOM) 
where  he  spent  11  years  as  lead  for  the  CGF/SAF,  HLA  and  Linux  Porting  developments  on  the  Close 
Combat  Tactical  Trainer  (CCTT)  system  in  addition  to  being  a  OneSAF  team  member.  His  twenty  years  with 
the  Government  have  been  mainly  in  CGF  and  Software  acquisition.  He  received  a  BSE  in  Electrical 
Engineering  and  an  MS  in  Systems  Simulation  from  the  University  of  Central  Florida. 


VIDEO  GAME  TRAINING 


Eric  Minton 
Today’s  Officer 
January  24, 2005 


Here  is  something  parents  everywhere  won’t  want  to  read:  video  games  can  make  you  smarter.  Not  that  you 
should  let  your  kids  sit  six  hours  in  front  of  a  computer  or  Xbox  playing  virtual  warriors.  But  when  such  stints 
use  real-life  scenarios,  include  constant  feedback  and  ratings,  and  meld  with  an  overall  training  regimen  that 
includes  book  study  and  live  experience,  video  games  make  for  a  wiser  and  more  adaptable  individual  and 
team  player. 


That  is  what  the  U.S.  military  is  discovering  as  each  branch  embraces  video  games  and  gaming  technology  in 
their  training  regimens.  This  is  more  just  catering  to  a  generation  that  knew  the  joy  of  joysticks  while  growing 
up  instead  of  toy  soldiers  and  teddy  bear  tea  parties.  This  is  a  trend  driven  by  available  technology,  by  budget 
constraints,  by  gaming’s  effectiveness  in  developing  social  and  cognitive  skills,  and  by,  well,  a  generation  of 
new  soldiers,  sailors  and  airmen  who  have  known  the  joy  of  the  joystick  all  their  lives. 


“Frankly,  every  18-year-old  has  played  a  video  game,”  says  Michael  Macedonia,  chief  technology  officer  for 
the  U.S.  Army’s  Program  Executive  Office  for  Simulation  Training  and  Instrumentation  (PEO  STRI)  in 
Orlando,  Florida.  “Every  1 8-year-old  coming  in  the  Army  knows  how  to  read,  too.  This  is  just  another 
technology  out  there  (Army  training)  can  take  advantage  of.”  He  points  out  that  Army  schools  used  to  play 


Avalon  Hill  battle  board  games,  too.  “The  bottom  line  is  we  will  do  anything  so  that  we  don’t  have  to  train 
through  blood.” 


Virtual  blood  is,  of  course,  part  of  the  video  gaming  culture,  which  brings  us  to  the  tricky  definition  of  “gaming” 
technology.  For  the  military  it’s  the  ability  to  do  the  latest  bells  and  whistles  or,  in  video  game  land,  special 
effects  and  interactive  graphics.  Layer  into  that  the  Internet  and  you  have  games  played  simultaneously  by 
participants  in  classrooms,  aboard  ships,  on  aircraft  and  in  bunkers.  “We  define  what  a  game  is  by  the 
emotional  response  in  a  player,”  says  Rosemary  Garris,  research  psychologist  with  the  Training  and  Human 
Performance  Research  and  Development  Branch  at  the  Naval  Air  Warfare  Center  Training  Systems  Division 
in  Orlando,  Florida.  Some  of  this  she  describes  as  the  “silliness  factor:”  the  player  hits  a  target  or  right  answer 
and  gets  an  explosion  or  gleeful  noise  as  reward.  Games  also  track  performance  measurements,  Garris  says; 
i.e.  keeps  score. 


Given  these  fun  responses,  the  tug  at  our  competitive  natures  and  the  ever-improving  graphic  displays  every 
person  interviewed  for  this  story,  from  instructor  to  engineer  to  Marine  colonel,  used  the  word  “cool”  at  least 
once  games  have  an  advantage  over  other  media  in  a  training  curriculum  in  that  they  enrapture  and  motivate 
the  students.  Remember,  though,  the  word  “game”  is  not  always  about  fun:  think  of  the  seriousness  with 
which  the  military  has  always  used  that  word,  as  in  “war  games.”  Thus,  the  primary  purpose  of  video  games  in 
training  is  to  improve  cognitive  and  decision-making  skills.  Though  some  games  and  simulator  programs 
teach  manual  procedures  and  dexterity,  the  majority  used  by  the  military  are  mental  games. 

Military  video  game  developers  therefore  make  sure  the  experience  is  about  handling  a  scenario  rather  than 
winning.  “One  of  the  potential  drawbacks  to  using  gaming  technologies  is  that  instead  of  the  learning  points 
and  proper  tactics,  techniques  and  procedures  you  are  trying  to  get  across,  (the  student)  wins  by  knowing 
how  the  game  works,”  says  Michael  Woodman,  project  manager  for  the  Marine  Corps  Tactical  Decision¬ 
making  Simulations  (TDSs).  In  other  words,  when  developing  video  games  for  military  training,  “We  don’t 
allow  cheat  codes.” 


The  four  services  work  with  established  game  developers,  such  as  the  Institute  for  Creative  Technologies  at 
the  University  of  Southern  California,  Forterra  Systems  Inc.  and  BreakAway  Games,  to  customize  the  games 
for  their  specific  training  needs.  One  such  game  is  the  Army’s  version  of  one  of  the  most  popular  games  on 
the  Internet,  Full  Spectrum  Warrior,  a  3-D  strategy  game  in  which  the  player  maneuvers  an  infantry  squad. 
“You  don’t  fire  your  weapon,  you  have  to  fire  the  squad,”  Macedonia  says.  “You  have  to  be  successful  in  the 
mission,  not  lose  any  people,  and  follow  the  rules  of  engagement.”  The  Army  also  is  developing  a  project 
called  the  Asymmetric  Warfare  Environment,  a  massive  database  server  containing  myriad  3-D  virtual  worlds 
that  can  be  networked  with  personal  computers  and  laptops  anywhere  in  the  world.  “You  could  build  a  place 
like  Fallujah,  and  people  can  go  train  in  Fallujah  whether  they  are  in  Tikrit  or  Alabama,  and  they  can  train 
together  and  ride  together,”  Macedonia  says. 


A  new  version  of  the  Marine  Corps’  Close  Combat:  First  to  Fight  takes  the  artificial  intelligence  quotient  a  step 
further  by  giving  all  virtual  members  of  the  fire  team  abilities  in  Marine  Corps  doctrine  known  as  “Ready- 
Team-Fire-Assist.”  Instead  of  the  player  micro  maneuvering  the  members  of  his  team,  those  members 
automatically  engage  in  mutual  support  tactics,  “just  like  a  real  Marine  would,”  Woodman  says.  “So,  the  fire 
team  leader  can  focus  on  his  responsibilities  as  a  team  leader,  focus  on  the  commands  he  needs  to  give 
when  they  are  called  for.”  The  game  could  be  set  to  a  multiplayer  mode,  too,  with  other  Marines  maneuvering 
the  team  members.  The  Marine  Corps  also  is  developing  an  Anti-Terrorism  TDS  in  which  the  player  conducts 
real-time  strategy  from  a  third-person  point  of  view,  and  Joint  T erminal  Attack  Controller  (JTAC),  which 
provides  a  first-person  point  of  view  to  a  developing  battle.  The  two  games  will  be  interoperable  so  that  a 
platoon  commander  can  maneuver  forces  using  the  Anti-Terrorism  TDS  while  those  forces,  using  JTAC, 
actually  engage  in  the  virtual  battlefield.  First  to  Fight  will  even  be  layered  into  the  system.  “It  will  enable  us  to 
work  back  and  forth  across  the  levels,”  Woodman  said. 


The  U.S.  Air  Force  is  using  such  networking  capabilities  to  create  a  Distributed  Mission  Operations  system 
hooking  up  different  flight  simulator  sites  around  the  world  so  that  various  crews  can  train  together.  This  will 
allow  virtual  training  of  four-ship  formations  with  other  four-ship  formations,  with  AWACS  and  with  JSTARS 
and  eventually  with  forward  ground  controllers  all  without  spending  an  ounce  of  jet  fuel.  Meanwhile,  on  a 
much  simpler  level  of  technology  and  a  heightened  level  of  silliness,  the  syllabus  for  the  Air  Force’s  T-38 
pilots  in  training  at  Randolph  Air  Force  Base,  Texas,  now  includes  a  video  game  put  together  by  Andrew 


Ranft,  program  manager  for  T-38  Courseware  at  Air  Education  and  Training  Command  Headquarters.  With 
cockpit  graphics  and  audio  feedback,  the  hour-long  game  is  intended  as  a  refresher  test  on  T-38  emergency 
procedures  and  operating  limitations  before  the  pilots’  check  flights.  The  four-part  format  is  based  on  popular 
television  game  shows:  Jeopardy,  Wheel  of  Fortune,  Who  Wants  To  Be  a  Millionaire  (rise  in  rank  from  cadet 
to  chief  of  staff  by  answering  questions:  a  wrong  answer  ends  the  game  with  the  computer  emcee  saying 
“You  are  dismissed!”),  and  Hollywood  Squares,  an  assembly  of  nine  cartoon  characters  such  as  a  crusty  old 
instructor  pilot  and  retired  SR-71  pilot  giving  answers  that  may  or  may  not  be  correct.  “Everybody  who  sees  it 
is  wowed  by  it  because  it  is  so  out  of  character  of  our  normal  courseware,”  Ranft  says. 


In  the  Navy,  submarine  trainees  take  a  Virtual  Interactive  Shipboard  Instructional  Tour  (VISIT),  a  scavenger 
hunt  to  get  students  acquainted  with  the  ship,  a  game  that  is  being  expanded  to  include  other  types  of 
vessels.  Submariners  also  undertake  a  lot  of  training  while  underway,  and  because  subs  don’t  have  room  for 
full-scale  simulators,  sailors  use  laptops  to  play  the  Submarine  Skills  Training  Network  featuring  periscope 
and  equipment  simulations.  With  the  latter,  the  Navy  is  incorporating  gaming  elements,  Garris  says,  such  as 
vivid  color,  dynamic  sequences  and  various  feedback  and  effects.  “Our  theory  is  if  you  put  the  right 
components  in,  hopefully  you  can  create  those  emotional  responses  in  players  that  would  encourage 
behaviors  you  want  in  students,”  she  says.  In  tests,  students  who  had  used  the  simulators  with  game 
components  scored  better  than  those  students  who  used  the  more  traditional  training. 


This  is  a  rare  instance  of  researched  data  showing  the  cognitive  benefits  of  computer  games  in  training 
regimens.  More  prevalent  is  anecdotal  evidence  endorsing  video  gaming’s  effectiveness.  Marine  and  Army 
officials  say  that  informal  surveys  indicate  that  infantry  units  practicing  on  computers  performed  better  in  live 
training  than  units  which  had  not  gone  through  virtual  training.  “You  get  over  the  rough  learning  points  in  a 
very  inexpensive  manner,”  Woodman  says  of  video  game  training.  “When  you  go  to  live  training  you’re  past 
the  little  stuff,  and  the  training  you  can  do  there  is  more  advanced.  Those  Marines  who  spent  a  week  with  us 
(on  TDSs)  going  into  the  field  were  better  trained  than  Marines  that  had  already  spent  two  weeks  in  the  field.” 
Cost-effectiveness,  as  much  as  cognitive-effectiveness,  is  a  major  part  of  the  equation  in  video  game  training 
and  simulation.  “Live  field  training  is  very  expensive  in  terms  of  time,  support,  ranges,  fuel,  ammunition,  the 
whole  gamut,”  Woodman  says.  Consider  the  cost  of  MOUT  training,  Military  Operations  in  Urban  Terrain.  In 
live  training  a  unit  could  perform  perhaps  three  evolutions  “on  a  good  day,”  Woodman  says.  On  computer  that 
unit  can  do  up  to  40  evolutions,  honing  skills  through  repetition  and  feedback.  The  computer  also  can 
introduce  a  variety  of  iterations  and  terrain,  something  not  possible  in  a  live  setting.  “That  is  not  to  say  these 
games  will  ever  replace  live  training;  we  design  them  to  augment  live  training,”  Woodman  says. 


“For  the  true  experience  you  can’t  do  any  better  than  doing  it  for  real,  doing  it  live,”  Colonel  Walt  Augustin, 
program  manager  for  Training  Systems,  Marine  Corps  Systems  Command  in  Orlando.  “But,  I  would  submit 
that  you  can  learn  certain  skills  faster  on  a  game  because  you  can  go  through  it  quickly,  repetitively  and  get 
immediate  feedback.” 


Saving  money  has  always  been  the  inspiration  behind  flight  simulators  since  the  1930s;  a  student  pilot  who 
makes  a  mistake  in  flight  can  destroy  an  expensive  aircraft,  and  the  best  way  to  practice  avoiding  fire  is 
through  simulation.  “We  don’t  like  to  shoot  missiles  at  our  good  airplanes,”  says  Mark  Adducchio,  director  of 
engineering  for  the  Simulator  Systems  Group,  Agile  Combat  Support  Wing  at  Wright  Patterson  Air  Force 
Base  in  Ohio.  “You’re  actually  flying  against  perceived  enemy  aircraft  and  ground  targets  you  can’t  really  do 
without  simulation.  We  strive  to  make  our  pilots  sweat  in  our  simulator  cockpits.” 


Macedonia  believes  the  Army  turned  to  simulation  training  after  the  Vietnam  War  because  not  only  were 
soldiers  in  that  war  poorly  trained  for  the  type  of  combat  they  encountered,  but  an  all-volunteer  Army  made 
proper  training  a  smart  investment.  “We  were  now  actually  investing  in  human  capital.  That  was  a  big  attitude 
change,”  he  says.  “So,  the  expenses  that  went  into  flight  simulators  (in  the  Air  Force  and  Navy)  went  into 
training  simulators  (in  the  Army).  What  we’re  trying  to  do  in  training  is  to  create  virtual  veterans.  We  want 
soldiers  to  years  later  remember  a  simulation  and  go,  That  was  an  awful  experience.’” 


The  military  did  not  jump  into  the  gaming  field  until  commercial  companies,  developing  games  for  consumer 
entertainment,  had  developed  the  technology  to  the  point  that  the  services  could  afford  to  co-opt  it.  “As  the 
technology  improved,  we  were  able  to  drive  cost  down,”  Macedonia  says.  The  Navy  hopes  to  drive  the  cost  of 
video  game  training  down  even  further  by  developing  a  gaming  engine  through  open  source  technology, 


downloading  bits  and  pieces  of  technology  from  the  Internet.  This  would  avoid  licensing  fees,  says  Curtis 
Conkey,  principal  investigator  for  the  Naval  Education  and  Training  Command  Personal  Computer  Simulation 
Experimentation  Lab  in  Orlando.  “In  the  Department  of  Defense  a  lot  of  technology  has  already  been  used  for 
the  high-profile  simulators,”  Conkey  says.  “There’s  a  whole  layer  below  that  of  less  critical  trainers  that  still 
need  to  be  built,  has  less  budget  and  can’t  afford  a  commercial  gaming  solution  or  the  recurrent  licensing  fees 
of  gaming.”  The  engine  is  being  built  at  www.delta3D.org. 


The  technology,  which  has  come  so  far  so  fast  in  the  1 0  years  since  a  couple  of  young  Marines  adapted  the 
coding  of  the  game  Doom  to  make  it  relevant  to  Marine  Corps  training,  is  still  in  its  infancy.  “We’re  gong 
through  changes  as  we  speak,”  says  Col.  Augustin.  He  was  talking  about  both  the  technology  of  video 
gaming  and  acceptance  of  video  gaming  in  military  training.  “Advocates  at  service  schools  are  very  proactive 
in  implementing  this  technology  in  their  courses  and  instruction.  Others  are  more  reluctant  or  resistant  to  the 
potential.”  For  his  part,  Augustin  wishes  he  had  such  video  game  training  as  a  young  infantryman. 

Still,  even  the  most  proactive  aficionado  would  not  contend  that  video  gaming  in  its  current  state  can  replace 
live  experience.  But  the  time  may  come  when  computers  can  provide  sense  surround  noises,  vibrations  and 
smells.  Even  today,  graphics  and  computer  effects  can  make  an  emotional  impact,  which  is  where  training 
takes  hold.  Macedonia  says  that’s  the  marriage  of  psychology,  technology  and  art.  “Plain  reality  is  not  as 
good  as  an  artistic  version,”  he  says.  “The  human  mind  is  an  incredible  gift  of  God.  We  can  make  that  monitor 
disappear  for  people.” 


Woodman  has  seen  that  immersive  quality  take  hold  among  Marines  training  on  video  games.  One  instance 
was  loaded  with  irony  when  a  platoon  leader  in  feedback  session  criticized  video  gaming  because  it  could  not 
replicate  a  key  interaction  between  a  leader  and  his  men;  namely,  when  a  rifleman  isn’t  moving  to  the  right 
position  because  he’s  not  paying  attention  or  can’t  understand,  the  squad  leader  will  go  over  to  that  rifleman, 
grab  his  straps  and  point  him  to  the  proper  place.  Later  that  very  day  in  another  video  training  session, 
Woodman  says,  “I  watched  a  fire  team  leader  get  up  from  his  chair,  go  over  to  a  fire  team  member,  point  at 
the  computer  screen  and  say,  ‘Here!  I  want  you  here!”’ 


SIDEBAR:  THE  LINK  BETWEEN  WAR  AND  GAMES 


Eric  Minton 
Today’s  Officer 
January  25,  2005 

Edwin  A.  Link  developed  the  world’s  first  true  flight  simulator  in  1 929  to  train  pilots  how  to  fly  before  they  step 
into  the  cockpit.  He  built  it  for  the  U.S.  military,  but  because  of  budget  constraints  neither  the  Army  nor  Navy 
would  purchase  it.  So,  Link  sold  the  contraption  to  amusement  parks  as  a  ride.  The  armed  forces  bought  it 
during  the  pre  World  War  II  buildup. 


This  was  just  the  first  in  a  long  and  ongoing  link  between  the  amusement  industry  and  armed  forces, 
especially  in  the  training  arena.  Hollywood  used  its  A-list  actors  to  make  training  films  in  World  War  II.  Two 
U.S.  Navy  engineers  invented  laser  tag,  and  Army  trainers  were  the  first  to  put  it  to  extensive  use.  The 
engineers  who  developed  a  networked,  full-immersive  training  simulator  for  the  Army  allowing  helicopters  and 
armored  vehicles  to  train  together  in  virtual  reality  installed  a  similar  system  depicting  Formula  1  racing  at  a 
Las  Vegas  casino.  The  U.S.  military  and  NASA  developed  the  3-D  graphics  that  later  showed  up  in  Pong,  the 
dawn  of  the  video  game  age. 


In  the  past  1 0  years  the  technology  has  been  flowing  in  the  other  direction  as  military  development  budgets 
tighten  while  the  booming  entertainment  business  has  goaded  commercial  developers.  The  same  companies 
building  the  motion  platforms  and  graphic  displays  for  Star  Trek,  Disney  and  Universal  Studio  virtual  reality 
rides  provide  flight  simulators  for  U.S.  and  other  air  armed  forces.  For  video  game  technology,  the  armed 
forces  are  going  to  commercial  developers  to  customize  games  already  popular  among  the  general  public. 
“Entertaining  and  training  are  about  making  memories,”  says  Michael  Macedonia,  chief  technology  officer  for 
the  Army’s  Program  Executive  Office  for  Simulation  Training  and  Instrumentation.  “When  you  go  outside 


classroom  education,  what  you’re  trying  to  do  with  soldiers  is  provide  experience.  Entertainment  is  also  trying 
to  develop  experiences,  but  from  a  different  perspective:  pleasurable  experiences.” 


This  is  a  symbiotic  relationship,  even  in  a  physical  sense.  The  Army  (PEO  STI),  Navy  (Naval  Air  Warfare 
Center  Training  Systems  Division)  and  Marines  (Training  Systems,  Marine  Corps  Systems  Command)  all 
have  their  VR  and  simulator  development  centers  and  research  labs  in  Orlando,  co-located  with  many  of  the 
amusement  industry’s  top  simulation  and  show  control  engineering  firms.  By  partnering  with  commercial 
enterprises  on  developing  video  games,  the  services  get  access  to  proprietary  technology  while  the  game 
makers  get  access  to  military  expertise  in  tactics,  techniques  and  procedures,  not  to  mention  uniform  insignia. 
Macedonia  believes  the  symbiosis  goes  much  deeper  than  that.  It’s  all  about  story  telling.  Video  games, 
simulators  and  movies  tell  stories,  and  storytelling  can  also  make  training  stick.  “Stories  are  what  link  these 
atoms  of  facts  together  so  you  can  move  backward  and  forward  in  your  memory,”  Macedonia  says. 


THIRD  SEMIANNUAL  CBRN  DATA  MODEL  TECHNICAL  REVIEW  A  SUCCESS 

By  Sheila  Vachher,  CBRN  Data  Initiative  Technical  Lead 


The  Joint  Program  Manager  (JPM)  Information  Systems  (JPM  IS)  Data  Acquisition  Program  Manager  (APM), 
Dr.  Thomas  Johnson,  the  Chemical,  Biological,  Radiological,  Nuclear  (CBRN)  Data  Initiative  Team,  and  the 
Joint  Program  Executive  Office  for  Chemical  and  Biological  Defense  (JPEO-CBD)  Software  Support  Activity 
(SSA)  Data  Team  held  their  third  semiannual  Technical  Review  of  the  CBRN  Data  Model.  The  review  was 
held  on  January  10-12,  2006  in  Edgewood,  MD.  The  Data  Team’s  semiannual  Technical  Reviews  bring 
together  a  group  of  experts  from  across  the  CBRN  community  to  review  and  make  recommendations 
regarding  the  CBRN  Data  Model.  This  review  in  particular  provided  an  excellent  example  of  collaboration 
between  the  acquisition  and  the  science  and  technology  (S&T)  communities.  Although  the  CBRN  Data  Model 
is  a  product  of  the  acquisition  community,  Mr.  William  Ginley  of  the  Joint  Science  and  Technology  Office  for 
Chemical  Biological  Defense  (JSTO  CBD)  volunteered  to  host  the  meeting  at  the  Edgewood  Chemical 
Biological  Center  (ECBC)  Conference  Center,  and  several  individuals  from  the  S&T  community  participated  in 
the  review. 

The  CBRN  Data  Model  is  being  developed  by  JPM  IS  for  common  use  by  the  Joint  Warning  and  Reporting 
Network  (JWARN),  Joint  Effects  Model  (JEM),  and  Joint  Operational  Effects  Federation  (JOEF)  programs. 
Because  the  programs  share  a  common  data  model,  semantic  and  syntactical  inconsistencies  among  the 
programs  can  be  avoided.  This  both  facilitates  information  exchange  and  reduces  development  costs.  The 
CBRN  Data  Model  serves  as  a  repository  of  Common  Semantics  and  Syntax  (CSS)  for  JPM  IS  programs. 
Although  the  CBRN  Data  Model  is  currently  focused  on  JPM  IS  programs,  the  plan  is  for  it  to  evolve  and 
become  an  enterprise-wide  model,  spanning  all  CBRN  Defense  programs  for  all  JPMs.  Joint  Project  Manager 
Guardian  is  already  working  to  extend  the  CBRN  Data  Model  to  support  their  data  needs,  in  preparation  for 
adopting  the  CBRN  Data  Model  within  the  Guardian  program.  The  January  Technical  Review  of  the  CBRN 
Data  Model  focused  on  version  1 .3,  which  was  released  in  October  2005.  In  contrast  with  previous  reviews, 
this  review  focused  specifically  on  the  changes  that  were  made  between  versions  1 .2  and  1 .3  rather  than 
trying  to  cover  the  entire  model.  The  reasons  for  this  were  twofold. 

First,  many  attendees  had  attended  previous  reviews  and  had  a  good  understanding  of  the  overall  model 
already  and  secondly,  as  the  model  grows,  it  is  not  realistic  to  try  to  cover  all  the  details  in  a  few  days.  The 
review  did  include  an  overview  of  the  CBRN  Data  Model  methodology  and  structure  to  orient  new  attendees. 
One  of  the  most  significant  changes  between  versions  1 .2  and  1 .3  involved  the  addition  of  numerous 
transport  and  dispersion  variables  to  the  CBRN  Data  Model.  The  transport  and  dispersion  variables  added 
were  discussed  in  detail,  and  grouped  by  the  categories  of  meteorologyrelated  variables,  facility-related 
variables,  CBRN  event-related  variables,  and  CBRN  release  and  calculation-related  variables.  Another 
significant  change  in  version  1.3  was  the  addition  of  entities  and  attributes  to  describe  chemical  and  biological 
sensors,  and  to  support  capture  of  their  output.  This  necessitated  adding  entities  and  attributes  to  describe 
networks  and  electronic  addresses  as  well.  Entities  were  also  added  for  radiation  sensors,  but  they  will  be 
more  fully  specified  in  version  1.4  (due  out  Spring  2006). 


Responding  to  the  community’s  requests,  the  Data  Team  presented  a  use  case  demonstrating  how  to  use  the 
data  model  for  a  specific  CBRN  event.  The  specific  example  traced  a  nuclear  detonation  because  it  would  be 
human  observable  and  make  use  of  numerous  related  entities.  The  Data  Team  outlined  which  entities  in  the 
data  model  would  need  to  be  populated  in  which  order  as  the  incident  progressed.  The  use  case  was  very 
well  received,  and  in  an  open  discussion  of  training  approaches,  several  attendees  recommended  basing 
future  Technical  Reviews  on  use  cases. 

Miscellaneous  other  changes  in  version  1 .3  were  also  presented  to  the  group.  These  included  the  remodeling 
of  entities  related  to  CBRN  event,  and  changes  to  control  feature.  In  addition,  U.S.  Mission  Oriented 
Protective  Posture  (MOPP)  Levels  and  some  population  information  were  added. 

In  addition  to  the  sessions  that  focused  on  the  CBRN  Data  Model  itself,  on  the  first  day,  Mr.  David  Godso 
from  the  SSA  briefed  the  group  on  architecture  from  the  point-of-view  of  the  JPEO-CBD.  On  the  second  day 
of  the  Review,  Cmdr.  Rex  Cobb  and  Dr.  Glenda  Hayes  from  the  Defense  Information  Systems  Agency  (DISA) 
briefed  the  group  on  Net-centric  Enterprise  Services  (NCES)  and  Service-Oriented  Architectures  (SOA). 
These  briefings  were  quite  pertinent  since  the  common  CBRN  Data  Model  and  XML  schema  facilitate 
implementation  of  the  NCES-compliant  SOA. 

The  recommendations  made  by  attendees  throughout  the  three-day  meeting  were  documented  in  the  form  of 
action  items.  These  were  reviewed  with  the  group,  and  have  been  published  to  the  CBRN  Data  Model 
distribution  list.  Along  with  the  conference  presentations,  the  action  items  can  be  found  on  the  JPEO-CBD 
Integrated  Digital  Environment  (IDE)  at  the  following  link:  https://ipeocbd.altess.army.mil.  After  logging  into 
the  IDE,  please  follow  these  links  Software  Support  Activity/  Data/Data  Products/Data  Model  Technical 
Reviews/  to  see  information  about  the  current  and  previous  reviews. 

Approximately  55  people  from  a  wide  variety  of  backgrounds  attended  the  technical  review.  The  JWARN, 

JEM  and  JOEF  programs  were  represented.  There  were  also  representatives  from  JPM  IS,  Joint 
Requirements  Office  (JRO),  JPM  Biological  Defense  (JPM  BD),  JPM  Nuclear  Biological  Chemical 
Contamination  Avoidance  (JPM  NBC  CA),  JSTO  CBD,  Defense  Threat  Reduction  Agency  (DTRA),  ECBC, 
Joint  Medical  Information  Systems  Office  (JMISO),  and  Office  of  the  Chief  of  Naval  Operations  (OPNAV) 
among  others.  In  addition,  a  representative  from  Defence  Science  and  Technology  Laboratory  (DSTL)  in  the 
United  Kingdom  (UK)  attended  the  technical  review.  The  UK  plans  to  use  the  CBRN  Data  Model  for  some 
new  systems  they  are  developing,  so  they  are  taking  a  strong  interest  in  the  development  of  the  CBRN  Data 
Model. 

The  next  semiannual  CBRN  Data  Model  Technical  Review  is  slated  to  be  held  in  July,  2006  in  San  Diego, 

CA,  although  the  exact  dates  and  location  have  not  yet  been  set.  In  general,  and  at  the  request  of  attendees, 
the  Technical  Reviews  will  alternate  between  the  East  and  West  Coasts,  although  there  may  be  occasional 
exceptions. 
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